comments

diff --git a/doc/bugs/35_failed_tests_on_beegfs/comment_12_39d94818a0e2f989da37953c1585161e._comment b/doc/bugs/35_failed_tests_on_beegfs/comment_12_39d94818a0e2f989da37953c1585161e._comment
new file mode 100644 (file)
index 0000000..d2a9f89
--- /dev/null
+++ b/doc/bugs/35_failed_tests_on_beegfs/comment_12_39d94818a0e2f989da37953c1585161e._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2025-09-06T17:11:55Z"
+ content="""
+There are a few other races where a FD can leak to a child process still,
+where `setFdOption` is used after dup()/pipe().
+
+These don't involve files, so won't affect beegfs. They should still be
+fixed. 
+
+----
+
+While dup3() and pipe2() allow setting the close-on-exec flag,
+I don't think they're portable enough to rely on.
+
+It may be possible to rewrite these handful of things to avoid the problem:
+
+* processTranscript should be able to read chunks from stdout and stderr
+  concurrently and interleave, not needing a pipe
+* Remote.Directory should be able to reuse the same handle passed to fileContentCopier
+  to get the FD for the postchecknoncow.
+* gpg feedRead may be able to use stdin as the passphrase-fd. If gpg reads
+  one line for that, and then continues to read the rest of stdin for the
+  content to encrypt/decrypt. I have not checked if gpg behaves that way.
+* Similar for StatelessOpenPGP
+
+Alternatively, it would be possible to solve all of these issues, as well
+as the openTempFile race, by making the wrappers in Utility.Process prevent
+starting a process when a global MVar is empty. And have a function that
+runs an action with the MVar emptied. Then the call to dup/pipe could run
+effectively atomically with the `setFdOption`. There would be a small
+overhead in checking the MVar on each exec, but probably too small to be
+noticable.
+"""]]

diff --git a/doc/bugs/35_failed_tests_on_beegfs/comment_13_e7346cc5c2946bf0e7bbea8001ebaf2f._comment b/doc/bugs/35_failed_tests_on_beegfs/comment_13_e7346cc5c2946bf0e7bbea8001ebaf2f._comment
new file mode 100644 (file)
index 0000000..de6ff9b
--- /dev/null
+++ b/doc/bugs/35_failed_tests_on_beegfs/comment_13_e7346cc5c2946bf0e7bbea8001ebaf2f._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2025-09-06T17:28:57Z"
+ content="""
+There is some potential for any of these FD leaks to compromise security,
+in cases where a child process ends up running untrusted code in some kind
+of sandbox, that is sufficiently leaky that the leaked FD is accessible
+inside the sandbox.
+
+I don't think any existing special remote or other git-annex addons behave
+that way, so don't think this is an exploitable security hole. Arguably, if
+sandboxing untrusted code, it's on you to avoid exposing open Fds to it.
+
+However, since security is involved, it does need to be fixed comprehensively
+in git-annex, including the remaining races.
+
+And, I have decided that this fix can't be tied to the OsPath flag being
+set. It needs to be fixed when git-annex is built without that flag, or the
+flag needs to go away.
+"""]]